<html>
<body>
<body bgcolor="white" vLink=#ff8800 aLink=#cc3232 link=#bb4400>
<title>CSE 533 - Fall 2011</title>

<style type="text/css">body{margin: 0px 30px 0px 40px;} 
</style>

<h1>CSE 533 (Fall 2011) - Assignment 2</h1>
<h4>Due date: Friday, October 28, at 11:55pm</h4>

<p><big>You are to work on this assignment in groups of three students.
</big></p>

<h2>Overview</h2>
<p>The aim of this assignment is to practice <i>UDP</i> socket client 
/ server programming with a focus on two broad aspects :</p>

<ul>
<li>Setting up the exchange between the client and server in a secure way 
despite the lack of a formal connection (as in <i>TCP</i>) between the two, 
so that "outsider" <i>UDP</i> datagrams (broadcast, multicast, unicast -
fortuitously or maliciously) cannot intrude on the communication.</li>
<li>Introducing application-layer protocol data-transmission reliability, 
flow control and congestion control in the client and server using 
<i>TCP</i>-like <i>ARQ</i> (automatic repeat request) sliding window 
mechanisms.
</ul>

<p>The second item above is much more of a challenge to implement than 
the first, though neither is particularly trivial. But they are not 
tightly interdependent; each can be worked on separately at first and 
then integrated together at a later stage.</p>

<p>Apart from the material in Chapters 8, 14 & 22 (especially Sections 
22.5 - 22.7), and the experience you gained from the preceding assignment, 
you will also need to refer to the following :</p>
<ul>
<li>The <i>ioctl</i> function (Chapter 17).</li>
<li><i>get_ifi_info</i> function (Section 17.6, Chapter 17). This function 
will be used by the server code to discover its network interfaces so that 
it can <i>bind</i> all its interface <i>IP</i> addresses (see Section 22.6).
</li>
<li>Race conditions (Section 20.5, Chapter 20)</li>
</ul>

<p>You also need a thorough understanding of how the <i>TCP</i> protocol 
implements reliable data transfer, flow control and congestion control. 
Chapters&nbsp;17-&nbsp;24 of &nbsp;<a href=" http://docs.online.bg/NETWORKING/tcp-ip-illustrated/index.htm"> <i>TCP/IP Illustrated</i>, Volume&nbsp;1</a>
&nbsp; by W. Richard Stevens gives a good overview of <i>TCP</i>. Though 
somewhat dated for some things (it was published in 1994), it remains, 
overall, a good basic reference.


<p>You will implement a primitive file transfer protocol for <i>Unix</i> 
platforms, based on <i>UDP</i>, and with <i>TCP</i>-like reliability added 
to the transfer operation using timeouts and sliding-window mechanisms, and 
implementing flow and congestion control. The server is a concurrent server 
which can handle multiple clients simultaneously. A client provides the 
server with the name of a file. The server forks off a child which reads 
directly from the file and transfers the contents over to the client using 
<i>UDP</i> datagrams. The client prints out the file contents as they come 
in, in order, with nothing missing and with no duplication of content, 
directly on to <i>stdout</i> (via the receiver sliding window, but with no 
other intermediate buffering). The file to be transferred can be of 
arbitrary length, but its contents are always straightforward <i>ascii</i> 
text. Note that assuming the file contents <i>ascii</i> is not as 
restrictive as it sounds. One can always encode other types of files, 
for example, binary files using <i>base64 encoding</i> to make them into 
ASCII type. 


<h2>Arguments for the server</h2>

<p>You should provide the server with an input file <i>server.in</i> from 
which it reads the following information, <b>in the order shown, one item 
per line</b>&nbsp;:</p>

<ul>
<li>Well-known port number for server.</li>
<li>Maximum sending sliding-window size (in number of datagrams).</li>
</ul>

<p>You will not be handing in your <i>server.in</i> file. We shall create 
our own when we come to test your code. So it is important that you stick 
strictly to the file name and content conventions specified above. The 
same applies to the <i>client.in</i> input file below.</p>

<h2>Arguments for the client</h2>

<p>The client is to be provided with an input file <i>client.in</i> from 
which it reads the following information, <b>in the order shown, one item 
per line</b>&nbsp;:</p>

<ul>
<li><i>IP</i> address of the server (<b>not</b> the <i>hostname</i>).</li>
<li>Well-known port number of server.</li>
<li><i>filename</i> to be transferred.</li>
<li>Receiving sliding-window size (in number of datagrams).</li>
<li>Random generator <i>seed</i> value.</li>
<li>Probability <i>p</i> of datagram loss. This should be a real number in 
the range [&nbsp;0.0&nbsp;,&nbsp;1.0&nbsp;]&nbsp; (value 0.0 means no loss 
occurs; value 1.0 means all datagrams all lost).</li>
<li>The mean <i>&micro;</i>, <b>in milliseconds</b>, for an exponential 
distribution controlling the rate at which the client reads received 
datagram payloads from its receive buffer.</li>
</ul>

<h2>Operation</h2>

<ol>
<li>Server starts up and reads its arguments from file <i>server.in</i>.<br><BR>

As we shall see, when a client communicates with the server, the server 
will want to know what <i>IP</i> address that client is using to identify the server (<i>i.e</i>. , the destination <i>IP</i> address in the incoming datagram). Normally, this can be done relatively straightforwardly using the <i>IP_RECVDESTADDR</i> socket option, and picking up the information using the
ancillary data ("control information") capability of the <i>recvmsg</i> function. Unfortunately, Solaris 2.10 does not support the <i>IP_RECVDESTADDR</i> option (nor, incidentally, does it support the <i>msg_flags</i> option in <i>msghdr</i> - see <i>p</i>.390). This considerably complicates things.<br><BR>

In the absence of <i>IP_RECVDESTADDR</i>, what the server has to do as part of its initialization phase is to <i>bind</i> each <i>IP</i> address it has  (and, simultaneously,  its well-known port number, which it has read in from <i>server.in</i>) to a separate <i>UDP</i> socket. The code in Section 22.6, which uses the <i>get_ifi_info</i> function, shows you how to do that. However, there are important differences between that code and the version you want to implement.

<blockquote>
The code of Section 22.6 binds the <i>IP</i> addresses <i>and forks off a child</i> for each address that is bound to. We do not want to do that. Instead you should have an array of socket descriptors. For each <i>IP</i> address, create a new socket and <i>bind</i> the address (and well-known port number) to the socket <i>without</i> forking off child processes. Creating child processes comes later, when clients arrive.<br><BR>

The code of Section 22.6 also attempts to <i>bind</i> broadcast addresses. We do not want to do this. It <i>bind</i>s a wildcard <i>IP</i> address, which we certainly do not want to do either. We should <i>bind</i> strictly only unicast addresses (including the loopback address).<br><BR>

The <a href="get_ifi_info.html"> <i>get_ifi_info</i></a> function (which the code in Section 22.6 uses) has to be modified so that it also gets the network masks for the <i>IP</i> addresses of the node, and adds these to the information stored in the linked list of <i>ifi_info</i> structures (see Figure 17.5, <i>p</i>.471) it produces. As you go binding each <i>IP</i> address to a distinct socket, it will be useful for later processing to build your own array of structures, where a structure element records the following information for each socket :<br><BR>

<ul>
<li><i>sockfd</i></li>
<li><i>IP</i> address bound to the socket</li>
<li>network mask for the <i>IP</i> address</li>
<li>subnet address (obtained by doing a bit-wise <i>and</i> between the <i>IP</i> address and its network mask)</li>
</ul><br>

Report, in a <i>ReadMe</i> file which you hand in with your code, on the modifications you had to introduce to ensure that only unicast addresses are bound, and on your implementation of the array of structures described above.<br>
</blockquote>

You should print out on <i>stdout</i>, with an appropriate message and appropriately formatted in dotted decimal notation, the <i>IP</i> address, network mask, and subnet address for each socket in your array of structures (you do not need to print the <i>sockfd</i>).<br><BR>

The server now uses <i>select</i> to monitor the sockets it has created for incoming datagrams. When it returns from <i>select</i>, it must use <i>recvfrom</i> or <i>recvmsg</i> to read the incoming datagram (see 6. below).<br><BR></li>

<li>When a client starts, it first reads its arguments from the file <i>client.in</i>.<br><BR></li>

<li>The client checks if the server host is &#8216;local&#8217; to its (extended) Ethernet. If so, <i>all</i> its communication to the server is to occur as <i>MSG_DONTROUTE</i> (or <i>SO_DONTROUTE</i> socket option). It determines if the server host is &#8216;local&#8217; as follows.

<blockquote>
The first thing the client should do is to use the modified <a href="get_ifi_info.html"><i>get_ifi_info</i></a> function to obtain all of its <i>IP</i> addresses and associated network masks.<br><BR>

Print out on <i>stdout</i>, in dotted decimal notation and with an appropriate message, the <i>IP</i> addresses and network masks obtained.<br><BR>

In the following, <i>IPserver</i> designates the <i>IP</i> address the client will use to identify the server, and <i>IPclient</i> designates the <i>IP</i> address the client will choose to identify itself.<br><br>

The client first checks whether the server is on the same host. If so, it should use the loopback address 127.0.0.1 for the server (<i>i.e</i>. , <i>IPserver</i>&nbsp;=&nbsp;127.0.0.1). <i>IPclient</i> should also be set to the loopback address.<br><br>

Otherwise it proceeds as follows:<br><BR>

<i>IPserver</i> is set to the <i>IP</i> address for the server in the 
<i>client.in</i> file. Given <i>IPserver</i> and the (unicast) <i>IP</i> 
addresses and network masks for the client returned by <i>get_ifi_info</i> 
in the linked list of <i>ifi_info</i> structures, you should be able to 
figure out if the server node is &#8216;local&#8217;, i.e., on the same
subnet or not. </blockquote>

If the client has multiple IP addresses, and the server host is 
&#8216;local&#8217;, the client chooses an <i>IP</i> address for itself, 
<i>IPclient</i>, which matches up as &#8216;local&#8217; according to 
your examination above. If the server host is not &#8216;local&#8217;, 
then <i>IPclient</i> can be chosen arbitrarily.<br><BR>

Print out on <i>stdout</i> the results of your examination, as to whether 
the server host is &#8216;local&#8217; or not, as well as the 
<i>IPclient</i> and <i>IPserver </i> addresses selected.<br><BR>

Note that this manner of determining whether the server is local or not is somewhat clumsy and &#8216;over-engineered&#8217;, and, as such, should be viewed more in the nature of a pedagogical exercise. Ideally, we would like to look up the server <i>IP</i> address(es) in the routing table (see Section 18.3). This requires that a routing socket be created, for which we need superuser privilege. Alternatively, we might want to dump out the routing table, using the <i>sysctl</i> function for example (see Section 18.4), and examine it directly. Unfortunately, <i>Solaris 2.10</i> does not support <i>sysctl</i>. <br><BR>

More to the point, using <i>MSG_DONTROUTE</i> where possible would seem to gain us efficiency, in as much as the kernel does not need to consult the routing table for every datagram sent. But, in fact, that is not so. Recall that one effect of <i>connect</i> with <i>UDP</i> sockets is that routing information is obtained by the kernel at the time the <i>connect</i> is issued. That information is cached and used for subsequent sends from the connected socket (see <i>p</i>.255).<br><BR></li>

<li>The client now creates a <i>UDP</i> socket and calls <i>bind</i> on <i>IPclient</i>, with 0 as the port number. This will cause the kernel to bind an ephemeral port to the socket.<br><BR>

After the <i>bind</i>, use the <i>getsockname</i> function (Section 4.10) to obtain <i>IPclient</i> and the ephemeral port number that has been assigned to the socket, and print that information out on <i>stdout</i>, with an appropriate message and appropriately formatted.<br><BR>

The client <i>connect</i>s its socket to <i>IPserver</i> and the well-known port number of the server.<br><BR>

After the <i>connect</i>, use the <i>getpeername</i> function (Section 4.10) to obtain <i>IPserver</i> and the well-known port number of the server, and print that information out on <i>stdout</i>, with an appropriate message and appropriately formatted.<br><BR>

The client sends a datagram to the server giving the <i>filename</i> for the transfer. This send needs to be backed up by a timeout in case the datagram is lost.<br><BR></li>

<li>
Note that the incoming datagram from the client will be delivered to the server at the socket to which the destination <i>IP</i> address that the datagram is carrying has been bound. Thus, the server can obtain that address (it is, of course, <i>IPserver</i>) and thereby achieve what <i>IP_RECVDESTADDR</i> would have given us had it been available.<br><BR>

Furthermore, the server process can obtain the <i>IP</i> address (this will, of course, be <i>IPclient</i>) and ephemeral port number of the client through the <i>recvfrom</i> or <i>recvmsg</i> functions.<br><BR>

The server forks off a child process to handle the client. The server parent process goes back to the <i>select</i> to listen for new clients. Hereafter, and unless otherwise stated, whenever we refer to the &#8216;server&#8217;, we mean the server child process handling the client&#8217;s file transfer, not the server parent process.<br><BR></li>

<li>
Typically, the first thing the server child would be expected to do is to close all sockets it &#8216;inherits&#8217; from its parent. However, this is not the case with us. The server child does indeed close the sockets it inherited, <i>but not the socket on which the client request arrived</i>. It leaves that socket open for now. Call this socket the &#8216;listening&#8217; socket.<br><BR>

The server (child) then checks if the client host is local to its (extended) Ethernet. If so, <i>all</i> its communication to the client is to occur as <i>MSG_DONTROUTE</i> (or <i>SO_DONTROUTE</i> socket option).<br><BR>

<blockquote>
If <i>IPserver</i> (obtained in 5. above) is the loopback address, then we are done. Otherwise, the server has to proceed with the following step.<br><BR> 

Use the array of structures you built in 1. above, together with the addresses <i>IPserver</i> and <i>IPclient</i> to determine if the client is &#8216;local&#8217;.<br><BR>

Print out on <i>stdout</i> the results of your examination, as to whether the client host is &#8216;local&#8217; or not.
</blockquote></li>

<li>The server (child) creates a <i>UDP</i> socket to handle file transfer to the client. Call this socket the &#8216;connection&#8217; socket. It <i>bind</i>s the socket to <i>IPserver</i>, with port number 0 so that its kernel assigns an ephemeral port.<br><BR>

After the <i>bind</i>, use the <i>getsockname</i> function (Section 4.10) to obtain <i>IPserver</i> and the ephemeral port number that has been assigned to the socket, and print that information out on <i>stdout</i>, with an appropriate message and appropriately formatted.<br><BR>

The server then <i>connect</i>s this &#8216;connection&#8217; socket to the client&#8217;s <i>IPclient</i> and ephemeral port number.<br><BR>

The server now sends the client a datagram, in which it passes it the ephemeral port number of its &#8216;connection&#8217; socket as the data payload of the datagram. This datagram is sent using the &#8216;listening&#8217; socket inherited from its parent, otherwise the client (whose socket is connected to the server&#8217;s &#8216;listening&#8217; socket at the latter&#8217;s well-known port number) will reject it. This datagram must be backed up by the <i>ARQ</i> mechanism, and retransmitted in the event of loss.<br><BR>

Note that if this datagram is indeed lost, the client might well time out and retransmit its original request message (the one carrying the file name). In this event, you must somehow ensure that the parent server does not mistake this retransmitted request for a new client coming in, and spawn off yet another child to handle it. How do you do that?<br><BR>

When the client receives the datagram carrying the ephemeral port number of the server&#8217;s &#8216;connection&#8217; socket, it re<i>connect</i>s its socket to the server&#8217;s &#8216;connection&#8217; socket, using <i>IPserver</i> and the ephemeral port number received in the datagram (see <i>p</i>.254). It now uses this reconnected socket to send the server an acknowledgment. Note that this implies that, in the event of the server timing out, it should retransmit two copies of its &#8216;ephemeral port number&#8217; message, one on its &#8216;listening&#8217; socket and the other on its &#8216;connection&#8217; socket (why?).<br><BR>

When the server receives the acknowledgment, it closes the &#8216;listening&#8217; socket it inherited from its parent. The server can now commence the file transfer through its &#8216;connection&#8217; socket.<br><BR>

The net effect of all these <i>bind</i>s and <i>connect</i>s at server and client is that no &#8216;outsider&#8217; <i>UDP</i> datagram (broadcast, multicast, unicast - fortuitously or maliciously) can now intrude on the communication between server and client.<br><BR></li>

<li>Starting with the first datagram sent out, the client behaves as follows.<br><BR>

Whenever a datagram arrives, or an <i>ACK</i> is about to be sent out (or, indeed, the initial datagram to the server giving the <i>filename</i> for the transfer), the client uses some random number generator (RNG) function <i>random</i>() (initialized by the <i>client.in</i> argument value <i>seed</i>) to decide with probability <i>p</i> (another <i>client.in</i> argument value) if the datagram or <i>ACK</i> should be discarded by way of simulating transmission loss across the network.<br></li>
</ol>

<h2>Adding reliability to <i>UDP</i></h2>

<p>The mechanisms you are to implement are based on <i>TCP Reno</i>. These include&nbsp;:
<ul>
<li>Reliable data transmission using <i>ARQ</i> sliding-windows, with <i>Fast Retransmit.</i></li>
<li>Flow control via receiver window advertisements.</li>
<li>Congestion control that implements&nbsp;:
<ul>
<li><i>SlowStart</i></li>
<li><i>Congestion Avoidance</i> (&#8216;<i>Additive-Increase</i>/<i>Multiplicative Decrease</i>&#8217; &ndash; <i>AIMD</i>)</li>
<li><i>Fast Recovery</i> (but without the <i>window-inflation</i> aspect of <i>Fast Recovery</i>)</li>
</ul></li>
</ul>

<p> Only some, and by no means all, of the details for these are covered below. The rest will be presented in class, especially those concerning flow control and <i>TCP Reno</i>&#8217;s congestion control mechanisms in general&nbsp;:&nbsp; <i>Slow Start</i>, <i>Congestion Avoidance</i>, <i>Fast Retransmit</i> and <i>Fast Recovery</i>.</p>

<ol>
<li>Implement a timeout mechanism on the sender (server) side. This is available to you from Stevens, Section 22.5 . Note, however, that you will need to modify the basic driving mechanism of Figure 22.7 appropriately since the situation at the sender side is not a repetitive cycle of send-receive, but rather a straightforward progression of send-send-send-send- . . . . . . . . . . .<br><BR>

Also, modify the <i>RTT</i> and <i>RTO</i> mechanisms of Section 22.5 as specified below. I will be discussing the details of these modifications and the reasons for them in class.<br><br>
<ul>
<li>Modify function <i>rtt_stop</i> (Fig. 22.13) so that it uses integer arithmetic rather than floating point. This will entail your also having to modify some of the variable and function parameter declarations throughout Section&nbsp;22.5 from <i>float</i> to <i>int</i>, as appropriate.<br><br></li>
<li>In the <i>unprrt.h</i> header file (Fig. 22.10) set&nbsp;:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>RTT_RXTMIN</i>&nbsp;&nbsp; to 1000 msec.&nbsp;&nbsp; (1 sec. instead of the current value &nbsp;&nbsp;3 sec.)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>RTT_RXTMAX</i>&nbsp; to 3000 msec.&nbsp;&nbsp; (3 sec. instead of the current value 60 sec.)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>RTT_MAXNREXMT</i>&nbsp; to 12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (instead of the current value 3)<br><br></li>
<li>In function <i>rtt_timeout</i> (Fig.&nbsp;22.14), after doubling the <i>RTO</i> in line&nbsp;86, pass its value through the function <i>rtt_minmax</i> of Fig.&nbsp;22.11 (somewhat along the lines of what is done in line&nbsp;77 of <i>rtt_stop</i>, Fig.&nbsp;22.13).<br><br></li>
<li>Finally, note that with the modification to integer calculation of the smoothed <i>RTT</i> and its variation, and given the small <i>RTT</i> values you will experience on the <i>cs</i>&nbsp;/&nbsp;<i>sbpub</i> network, these calculations should probably now be done on a millisecond or even microsecond scale (rather than in seconds, as is the case with Stevens&#8217; code). Otherwise, small measured <i>RTT</i>s could show up as 0 on a scale of seconds, yielding a negative result when we subtract the smoothed <i>RTT</i> from the measured <i>RTT</i> (line&nbsp;72 of <i>rtt_stop</i>, Fig.&nbsp;22.13).<br><br></li>
</ul>

Report the details of your modifications to the code of Section 22.5 in the <i>ReadMe</i> file which you hand in with your code.<br><BR></li>

<li> We need to have a sender sliding window mechanism for the retransmission of lost datagrams; and a receiver sliding window in order to ensure correct sequencing of received file contents, and some measure of flow control. You should implement something based on <i>TCP Reno</i>&#8217;s mechanisms, with cumulative acknowledgments, receiver window advertisements, and a congestion control mechanism.<br><BR>

For a reference on <i>TCP</i>&#8217;s mechanisms generally, see W. Richard Stevens, &nbsp;<a href=" http://docs.online.bg/NETWORKING/tcp-ip-illustrated/index.htm"> <i>TCP/IP Illustrated</i>, Volume&nbsp;1</a>&nbsp;, especially Sections 20.2 - 20.4&nbsp; of  &nbsp;<a href="http://docs.online.bg/NETWORKING/tcp-ip-illustrated/tcp_bulk.htm#20_0">Chapter&nbsp;20</a>&nbsp;,&nbsp; and Sections 21.1 - 21.8&nbsp; of  &nbsp;<a href="http://docs.online.bg/NETWORKING/tcp-ip-illustrated/tcp_time.htm#21_0">Chapter&nbsp;21</a>&nbsp;.<br><BR>

Bear in mind that our sequence numbers should count datagrams, not bytes as in <i>TCP</i>. Remember that the sender and receiver window sizes have to be set according to the argument values in <i>client.in</i> and <i>server.in</i>, respectively. Whenever the sender window becomes full and so &#8216;locks&#8217;, the server should print out a message to that effect on <i>stdout</i>. Similarly, whenever the receiver window &#8216;locks&#8217;, the client should print out a message on <i>stdout</i>.<br><br>

Be aware of the potential for deadlock when the receiver window &#8216;locks&#8217;. This situation is handled by having the receiver process send a duplicate <i>ACK</i> which acts as a <i>window update</i> when its window opens again (see &nbsp;<a href="http://docs.online.bg/NETWORKING/tcp-ip-illustrated/tcp_bulk.htm#fig_20_3">Figure&nbsp;20.3</a>&nbsp; and the discussion about it in <i>TCP/IP Illustrated</i>). However, this is not enough, because <i>ACK</i>s are not backed up by a timeout mechanism in the event they are lost. So we will also need to implement a <i>persist timer</i> driving <i>window probes</i> in the sender process (see &nbsp;<a href="http://docs.online.bg/NETWORKING/tcp-ip-illustrated/tcp_pers.htm#22_0">Sections&nbsp;22.1&nbsp;&amp;&nbsp;22.2</a>&nbsp; in Chapter&nbsp;22 of <i>TCP/IP Illustrated</i>). Note that you do not have to worry about the <i>Silly Window Syndrome</i> discussed in Section&nbsp;22.3 of <i>TCP/IP Illustrated</i> since the receiver process consumes &#8216;full sized&#8217; 512-byte messages from the receiver buffer (see 3. below).<br><BR>

Report on the details of the <i>ARQ</i> mechanism you implemented in the <i>ReadMe</i> file you hand in. Indeed, you should report on <b>all</b> the <i>TCP</i> mechanisms you implemented in the <i>ReadMe</i> file.<br><BR></li>

<li>Make your datagram payload a fixed 512 bytes, inclusive of the file transfer protocol header (which must, at the very least, carry: the sequence number of the datagram; <i>ACK</i>s; and advertised window notifications).<br><BR></li>

<li>The client reads the file contents in its receive buffer and prints them out on <i>stdout</i> <b>using a separate thread</b>. This thread sits in a repetitive loop till all the file contents have been printed out, doing the following.<br><BR>
It samples from an exponential distribution with mean <i>&micro;</i> milliseconds (read from the <i>client.in</i> file), sleeps for that number of milliseconds; wakes up to read and print all in-order file contents available in the receive buffer at that point; samples again from the exponential distribution; sleeps; and so on.<br><BR>
The formula &nbsp;&nbsp;&nbsp;&nbsp;-1&nbsp;&times;&nbsp;<i>&micro;</i>&nbsp;&times;&nbsp;<i>ln</i>(&nbsp;<i>random</i>(&nbsp;)&nbsp;)&nbsp;,&nbsp;&nbsp;&nbsp; where <i>ln</i> is the natural logarithm, yields variates from an exponential distribution with mean <i>&micro;</i>, based on the uniformly-distributed variates over&nbsp; (&nbsp;0&nbsp;,&nbsp;1&nbsp;)&nbsp; returned by <i>random</i>().<br><BR>
Note that you will need to implement some sort of mutual exclusion/semaphore mechanism on the client side so that the thread that sleeps and wakes up to consume from the receive buffer is not updating the state variables of the buffer at the same time as the main thread reading from the socket and depositing into the buffer is doing the same. Furthermore, we need to ensure that the main thread does not effectively monopolize the semaphore (and thus lock out  for prolonged periods of time) the sleeping thread when the latter wakes up. See the textbook, Section&nbsp;26.7, &#8216;<i>Mutexes: Mutual Exclusion</i>&#8217;,&nbsp; <i>pp</i>.697-701. You might also find Section&nbsp;26.8, &#8216;<i>Condition Variables</i>&#8217;,&nbsp; <i>pp</i>.701-705, useful.<br><br></li>

<li>You will need to devise some way by which the sender can notify the receiver when it has sent the last datagram of the file transfer, without the receiver mistaking that <i>EOF</i> marker as part of the file contents. (Also, note that the last data segment could be a &#8220;short&#8221; segment of less than 512 bytes &ndash; your client needs to be able to handle this correctly somehow.) When the sender receives an <i>ACK </i>for the last datagram of the transfer, the (child) server terminates. The parent server has to take care of cleaning up zombie children.<br><br>

Note that if we want a clean closing, the client process cannot simply terminate when the receiver <i>ACK</i>s the last datagram. This <i>ACK</i> could be lost, which would leave the (child) server process &#8216;hanging&#8217;, timing out, and retransmitting the last datagram. <i>TCP</i> attempts to deal with this problem by means of the <i>TIME_WAIT</i> state. You should have your receiver process behave similarly, sticking around in something akin to a <i>TIME_WAIT</i> state in case in case it needs to retransmit the <i>ACK</i>.<br><br>

In the <i>ReadMe</i> file you hand in, report on how you dealt with the issues raised here: sender notifying receiver of the last datagram, clean closing, and so on.<br></li>

</ol>

<h2>Output</h2>

<p>Some of the output required from your program has been described in the section <i>Operation</i> above. <font color="red">I expect you to provide <u>further</u> output &ndash; clear, well-structured, well-laid-out, concise but sufficient and helpful &ndash; in the client and server windows by means of which we can trace the correct evolution of your <i>TCP</i>&#8217;s behaviour in all its intricacies&nbsp;:</font>&nbsp; information (<i>e.g.</i>, sequence number) on datagrams and <i>ack</i>s sent and dropped, window advertisements, datagram retransmissions (and why&nbsp;:&nbsp; <i>dup ack</i>s or <i>RTO</i>); entering/exiting <i>Slow Start</i> and <i>Congestion Avoidance</i>, <i>ssthresh</i> and <i>cwnd</i> values; sender and receiver windows locking/unlocking; <i>etc.</i>, <i>etc.</i>&nbsp;.&nbsp;.&nbsp;.&nbsp;&nbsp;.
</p>

<blockquote><font color="red">The onus is on you to convince us that the <i>TCP</i> mechanisms you implemented are working correctly.</font> Too many students do not put sufficient thought, creative imagination, time or effort into this. It is not the TA&#8217;s nor my responsibility to sit staring at an essentially blank screen, trying to summon up our paranormal psychology skills to figure out if your <i>TCP</i> implementation is really working correctly in all its very intricate aspects, simply because the transferred file seems to be printing o.k. in the client window. Nor is it our responsibility to strain our eyes and our patience wading through a mountain of obscure, ill-structured, hyper-messy, debugging-style output because, for example, your effort-conserving concept of what is &#8216;suitable&#8217; is to dump your debugging output on us, relevant, irrelevant, and everything in between.</blockquote>


<h2>Hand-in</h2>

<p><font color="#FF0000"><b>Important:</b> - The criterion for a <u>successful</u> assignment is that it execute correctly on the Solaris 10 <em>compserv</em> (<u>not</u> the Linux <em>compute</em>) nodes in the <em>cs.sunysb.edu</em> domain; with clear, well-structured output that convinces us that the mechanisms you implemented are working correctly.</font><br><br>

You can only submit the source 
code and the documentation! <font color=red>No executable or object 
file is accepted; including them will result in deducted marks</font>. 
This means before you submit, you must make a clean submit directory 
that has only the required files in it. Source code includes only 
<tt>.c</tt> and <tt>.h</tt> files. The documentation includes two 
files: <tt>Makefile</tt> and <tt>Readme</tt>, with those names.  

<p>You should submit your code using Blackboard. Your submission must 
absolutely include a <i>Makefile</i> which :</p>

<ul>
<li>compiles your code using, where necessary, the Stevens&#8217; environment in the course account, <i>~cse533/Stevens/unpv13e_solaris2.10</i>; and<br><BR></li>

<li>gives the standard names <i>client</i> and <i>server</i> for the client & server executable produced.</li></ul>

<p>Each group hands in just one copy of the Assignment, under one and
only one member's login name. You must co-ordinate among your group so that
only one copy is submitted. <font color=red>A penalty will be exercised 
if more than one copy is submitted per group.</font></p>

<p>Do not forget to hand in the <i>ReadMe</i> file mentioned in item 1. 
of the section <i>Operation</i>, and items 1, 2 & 5 of the section <i>Adding reliability to UDP</i>. The first thing the <i>ReadMe</i> file should contain is an identification of the members in the group.

You may submit a .tar file instead of multiple files. In that event, 
you must include in your documentation what command to use to obtain
the source files from the .tar file. Note that this must run properly
on compserv as well.

<p><font color=blue><b>Blackboard submission only</b></font> -
The handing-in will be through Blackboard Assignments. Note that there
are more than one types of assignments supported by Blackboard. We do 
not use "SafeAssign" or "Digital Dropbox". Rather we use "Assignments" 
only. The submission instructions are at:
<a href=https://tlt.stonybrook.edu/StudentServices/BbStudents/Pages/SubmittingWork.aspx#assignments>
	https://tlt.stonybrook.edu/StudentServices/BbStudents/Pages/SubmittingWork.aspx#assignments</a>.
You must read the submission instructions very carefully, and check to 
make sure your assignment has been submitted correctly before the deadline.
You can only submit once! However you can save your work by clicking 
"Save" as many times as you like. Only click "Submit" after you have 
checked and are certain that all requirements are followed.

<h2>Grouping</h2>
The assignment is to be completed by groups of three students. The grouping
is determined randomly, and is shown <a href=http://www.cs.sunysb.edu/~cse533/Assts/A2/groups>here</a>. You must contact each other right away through 
Blackboard Tools -> Send Email. Then start to exchange phone numbers, 
meeting hours, etc.<br><br>

<font color=red><b>Working in groups</b></font>: 
Each student is expected to undertake similar amount of work within this 
assignment. Each student is also expected to be knowledgeable about the 
entire project. To work in a group takes good planning, organization, 
discussions, discipline, responsibility, negotiation, and hard-work. 
There will undoubtly non-uniformity within a group regarding students'
familarity with network programming and programming skills. Thus it is
important that the "faster" students do not monopolize the majority of
the work, and the "slower" students work hard to earn your credit. At 
the assignment due date, each student submits a <it>peer-assessement</it> 
via Blackboard as follows: <br><br> 

<font color=red><b>Peer-assessment scheme</b></font>: 
In an n-member group, each member assesses the contribution of the other 
n-1 members by allocating each a score out of 100, such that the total 
marks awarded is 100 * (n-1). More contribution receives higher marks.
If any individual score is higher than 110, or lower than 90, provide a 
short justification. If all members undertook the same amount of work, 
each member should receive 100. Note that because this is a programming
course, the "work" here mainly means programming work, other work such
as writing documentation should be considered very minor work.
<br><br>

<font color=red><b>Submission of the peer-assessment report</b></font>: 
Prepare a simple plain-text file called "groupX-LLLL.txt", where X is 
your group number, and LLLL is your last name. You must clearly 
identify on your report the names of the other two members that you
are evaluating. This report must be submitted via Blackboard. 
<br><br>

<font color=red><b>Resolving dispute</b></font>: 
Issues such as a member of a group is not completing his/her part of job 
must be quickly resolved. If no avail, contact the instructor right away.
The assignment's final mark is assigned taking into account the peer-
assessment marks. Please keep record as to what and when you and each 
other member have done with respect to this assignment work, and all 
the emails sent and received. Meetings will be called and marks be 
determined by the instructor to resolve any dispute that may arise. 
<br><br>


<p><b>
The due date is 11:55pm on Friday, October 28. No late submissions will be 
accepted.</b>

<h2>Completing the assignment</h2>
<font color=red><b>Warning:</b></font>
This is a very heavy and time-consuming assignment. You simply need 
to start working on it right away. 

<p>
<font color=blue><b>Incremental development</b></font> -
You are adviced to develop your programs <b>incrementally</b> - 
starting from a simple version, and then add the various functionalities 
and capabilities one at a time. 

<p><font color=blue><b>Blackboard discussion board</b></font> -
Read the man pages for various system calls and library functions.
Reading the related textbook pages is must. You should make use of the 
discussion board on Blackboard to ask and answer questions. A forum 
called "<b>UNP Assignment 2 forum</b>" will be created for this purpose. 
It will be read by the teaching staff and all students. Note that no 
exact answer to any question should be provided at any time by any 
student or teaching staff, online or offline. Hints can be provided 
but not the exact answers. 

<p><font color=red><b>Moss and academic integrity</b></font>
Your submitted code will be checked using the Stanford Moss package -
<i>A System for Detecting Software Plagiarism</i>, to detect cheating. 
<font color=red>Source code from previous years of this course, which 
has all been archived, and from the current offering, i.e., your 
classmates, will be checked against by this package</font>. Also 
keep in mind that important assignment materials are within the scope 
of the exams. So you must understand the major steps and knowledge 
elements of the assignment for your own benefit.<br><br>

<hr>
Last update: October 7, 2011<br><br>
</body>
</html>
